查看原文
其他

从一张图片引起的争论...

朱少民 软件质量报道 2022-11-09

(图片来自“真北敏捷” 微信群)


昨天在“真北敏捷” 微信群中看到上面这张照片,我就说,“只有等级六才是质量内建,其它(等级1-5)不算”,而有人说,敏捷中的质量内建都达不到这么高的要求。这算要求高吗?其实不是 “要求高不高” 的问题,而是 “是非问题“。质量内建就是在需求、设计、编程的时候尽可能把事情做对、做好,尽量不产生缺陷,简单地说:质量内建 = 缺陷预防,所以说,1-5不是质量内建,因为每个等级上面的活动强调 “验证、测试”,侧重发现缺陷,而不是预防缺陷,虽然下面写了“缺陷不暴露给用户”、“缺陷不离开...” ,只有等级六写上“不产生缺陷”、“更好的需求、设计和开发实践”,等级六才是真正的质量内建。所以,群里网友后来说:这个题目可以改为 “走向质量内建的六个层级”。


1. 质量内建有哪些实践?

在传统制造业,有质量检验(QC),对于硬件一旦有质量问题,就成为废品(次品),所以质量大师戴明说:检查不能提高质量,也不能保证质量。等检查发现问题,已经太迟了,因为无论产品的质量是好是坏都已经发生了。产品或服务的质量不能靠检验,质量必须内建。
“质量内建(Quality is built-in)” 或 “内建质量 (Built-in quality)” 由此而来。软件不同于硬件,即使发布以后也可以修改,但就可以不重视质量了吗?任何缺陷修改、返工都会造成浪费,加大企业成本,甚至需要赔偿客户的损失,付出惨重的代价。
质量内建有哪些实践呢?这里简单列一下,之前我在 第一届QECon大会的致辞 中就阐述过这个“质量内建”的主题。
  • 质量内建源于你的自尊,没有质量就没有尊严。在组织中构建良好的质量文化,宣传 并拥有“客户第一”、“零缺陷质量管理”、“质量是企业的生命力”等理念

  • 招聘优秀人才

  • 加强人员内部培训和培养,提升研发人员技能

  • TDD、ATDD和BDD,以及实例化需求

  • 制定设计规范、编程规范

  • 有明确的质量要求,包括明确要遵守的法律法规

  • 进行缺陷根因分析,反过来采取措施、建立/丰富checklist以预防缺陷

  • 建立知识库,供研发人员随时查询

  • 为质量改进、缺陷预防而持续改进流程

  • 需求建模、领域建模等

  • 为弹性、韧性而设计

  • 为测试设计:提高可测试性

  • 设计力求简单

  • 防御式编程

  • 编程时有实时检测代码违背规范等问题的机器人

  • 每天留半个小时,团队成员一起review代码,分享经验,相互学习

  • ......


2. 什么样的实践是“非质量内建”的?

强调质量内建,是体现了“零缺陷质量”管理思想,尽量一次把事情做对,但也不是 “任何缺陷都不能接受”、“不产生一个缺陷”。人总是要犯错的,事情干得越多可能犯的错误也越多, 可以接受缺陷,接受代码重构,只是从技术、流程、管理等各方面帮助团队尽可能少犯错误,如前面说的设计规范、编程规范和自我工作检查/反思的checklist等等,而不能依赖测试、依赖代码重构等。

强调质量内建,思想上有“一次把事情做对”的强烈意识,设计时会多考虑各种因素(如兼容性、性能、安全性等),就会少犯错误。正像有人说,即使不践行TDD,但有TDD思维,在写代码时,先在头脑中想想——写完这段代码,自己会犯什么错误?会漏掉什么场景?自己如何去验证写的代码没有问题?那么写出来的代码就会好不少。如果程序员受过防御式编程、TDD的训练,以及AI工具的辅助,质量更有保证。

违背质量内建的实践,有不少,例如:

  • 急着把不合格的人招进来

  • 让员工拼命加班,疲劳工作或精神状态不佳

  • 需求是自己想当然想出来的,而缺乏市场调查、行业分析和客户认知

  • 对待需求,漫不经心,随意写,评审流于形式

  • 写完代码,自己不看一眼,就直接丢给测试

  • 没有制定设计规范

  • 没有制定代码规范

  • 只关注交付速度,不关注交付价值和质量

  • ......


3. 一次做对还需要敏捷吗?

当年,戴明就是在日本企业工作时提出“质量内建”概念,也是丰田精益制造的核心实践,精益产品研发的七大原则的第2项就是“内建质量”,如下图所示。
  1. 消除浪费

  2. 内建质量

  3. 创造知识

  4. 推迟承诺

  5. 快速交付

  6. 尊重人

  7. 优化整体


精益特别强调价值流的流动,合作的上下游需要构成一个价值流。但并非有了上下游就能算是价值流。要成为价值流,要满足两个基本条件:(1)能创造价值;(2)过程中消除浪费,提升效能。确保整个开发价值流的快速流动,让质量成为每个人的工作。有了需求质量,才能更好地认知业务价值;有了高质量的研发,才能在研发过程中最大程度地消除浪费。
今天我们讨论敏捷时,也常常强调价值交付,常常把敏捷和精益联系在一起。在规模化敏捷模型SAFe中, Built-in Quality 是其核心价值观,质量内建是实现连续价值流的必要条件,所有团队(包括软件、硬件、运维、产品营销、法律、安全、合规等)都共享质量内建的目标和原则,见右下角,内容详见:https://www.scaledagileframework.com/built-in-quality/。质量内建实践确保每个解决方案元素,在每个增量上,在整个开发过程中满足适当的质量标准。企业以最短的持续交付时间交付新功能并适应快速变化的业务环境的能力取决于解决方案质量。所以说,敏捷和质量内建不矛盾。



我一直强调,实施敏捷开发模式,如果没有ATDD,团队最终不能敏捷起来。要真正能够持续敏捷(可持续性),也是尽可能预防缺陷(如TDD、ATDD等)。
敏捷侧重持续交付,要想交付快,更要高质量护航,这也是为什么我要发起 “软件质量效能大会(QECon)”,希望把质量和效能真正地融合起来,高质量带来高效能,而不是隔离地去看质量和效能,这样才会给企业带来更大的价值。

参考链接

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存